work with OSTree is instead to take the list of installed packages in
the currently booted tree, and compute a new filesystem from that. A
later chapter describes in more details how this could work:
-[adapting-existing.md](Adapting Existing Systems).
+[Adapting Existing Systems](adapting-existing.md).
For the purposes of this section, let's assume that we have a
newly generated filesystem tree stored in the repo (which shares
Given a commit to deploy, OSTree first allocates a directory for
it. This is of the form `/boot/loader/entries/ostree-$osname-$checksum.$serial.conf`.
-The `$serial` is normally 0, but if a
+The `$serial` is normally `0`, but if a
given commit is deployed more than once, it will be incremented.
This is supported because the previous deployment may have
configuration in `/etc` that we do not want to use or overwrite.
This "updates as code" model allows for multiple content generation
strategies. The design of this was inspired by that of Chromium:
-[http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate](ChromiumOS
-autoupdate).
+[ChromiumOS Autoupdate](http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate).
### The delta superblock
A later addition to OSTree is the concept of a "summary" file, created
via the `ostree summary -u` command. This was introduced for a few
reasons. A primary use case is to be a target a
-(Metalink)[https://en.wikipedia.org/wiki/Metalink], which requires a
+[Metalink](https://en.wikipedia.org/wiki/Metalink), which requires a
single file with a known checksum as a target.
The summary file primarily contains two mappings: